Computing systems (e.g., personal computers, servers) have conventionally included components like a central processing unit(s) (CPU), a ROM BIOS (read only memory basic input output system), different types of memory, input/output (I/O) devices, storage devices, and so on. The CPU, memories, devices, and so on, have typically been logically and physically connected by a bus. These conventional systems may not have been configured identically and may have included expansion slots that facilitated connecting other components like additional memory, additional I/O devices, specialized processors (e.g., graphics coprocessors), and the like.
To facilitate handling various configurations and/or the addition/removal of components, conventional systems may have included a base system that engaged in a startup procedure known as a boot sequence. The boot sequence may have included a discovery phase for discovering, for example, what devices were connected to the base system. Building a base system that included software (e.g., device drivers) to interact with every possible known device would have been unwieldy. Additionally, a base system built before a new technology came into existence could not possibly have included software configured to interact with devices built from the new technology. Thus, to facilitate dynamically configuring systems and to allow for the use of future technologies, some base systems were produced that were designed to interact with devices that provided their own device driver to the base system. Devices built to interact with such base systems may have included an option ROM that stored a device driver for the device. Thus, if the boot process for the base system was configured to find, load, and use a device driver provided in an option ROM, associating a device (even an after-invented device), with a base system was relatively straightforward.
By way of illustration, as a boot sequence discovered a device the boot sequence could load processor executable instructions like a device driver from an option ROM on the device. In one example, the base system boot sequence could load a device driver from an option ROM on a device into memory mapped I/O (MMIO) memory associated with the base system. Then, the base system boot sequence could execute the loaded device driver from that MMIO memory. However, MMIO memory is a finite and precious resource. Thus, as computing systems grow to include increasing numbers of devices organized into deeper hierarchical levels that communicate across ever-increasing numbers and types of busses, loading option ROM based device drivers into MMIO memory space may become undesirable.